Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve BarStack to work with all scales type #368

Merged
merged 5 commits into from
Oct 5, 2018

Conversation

lucafalasco
Copy link
Contributor

🚀 Enhancements

  • BarStack and BarStackHorizontal were currently broken if a scale other than ScaleBand was passed as scale prop; this enhance those components by checking for existence of specific interface functions and avoiding throwing errors with different scales.

🐛 Bug Fix

Copy link
Member

@hshoff hshoff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First, thanks for this. Before landing this, a couple of architecture thoughts.

  1. Instead of checking scale type we should check feature support.

This would mean

function scaleHasBandwidth(scale) {
  return isScaleBand(scale) || isScalePoint(scale)
}

becomes

function scaleHasBandwidth(scale) {
  return !!scale.bandwidth && typeof scale.bandwidth === 'function';
}

My reason for this is in the future we may add more scales and if those scales implement bandwidth() they should be able to work with BarStack without us having to update the shape implementation.

  1. if we check on feature support instead of scale type then we can drop the isScaleBand(), isScalePoint() util functions. This has the added benefit of don't have to add @vx/scale as a dependency to @vx/shape (smaller bundles, faster install times).

Let me know what you think about the above approach. Happy to land this PR as is, I just had a lot of coffee this morning.

@hshoff hshoff added this to the v0.0.178 milestone Oct 4, 2018
@lucafalasco
Copy link
Contributor Author

Yeah that's exactly the approach I initially considered.
The reasons I opted for the type property check here were essentially:

  1. I thought it could be useful/clearer (together with add scale type #367 ) to implement isScaleBand() etc. util functions also in other scenarios.

  2. If the d3 scales interfaces change, we just have to update the function that is executed and not the "check-for-existence" function, as the type remains the same.

Looking at it again though, I believe that, as you suggest, checking for feature support is probably better and more future proof if we add more scales implementing the same functions. Also, the smaller bundle is definitely a good point 😉

Copy link
Member

@hshoff hshoff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM thanks for the contribution!

@hshoff hshoff merged commit d070716 into airbnb:master Oct 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BarStack doesn't work with ScalePoint
2 participants